Transaction traps are BEGIN TRANSACTION, COMMIT, ROLLBACK, and SET TRANSACTION ISOLATION LEVEL.
When working with explicit transactions there are a few statements you can use to control the transaction. The BEGIN TRANSACTION statement is what tells SQL Server that you are starting a new explicit transaction. All commands after the BEGIN TRANSACTION
statement are included within the transaction. The transaction can be
named or not, marked or not, and will function the same either way. The
transaction will survive through multiple batches and multiple stored
procedures.
All statements will continue to be kept in the transaction until either the COMMIT or ROLLBACK statement is issued. The COMMIT statement tells SQL Server to write the completed statements to the database file. The ROLLBACK
statement tells SQL Server to roll back the statements, which leaves
the data in the same state it was before the transaction was started.
If you wish to change the transaction isolation level that SQL Server uses then you use the SET TRANSACTION ISOLATION LEVEL
statement. This will allow you to change the isolation level that the
connection is using. It will not affect any other transactions or
sessions on the instance, nor will it affect the default transaction
isolation level, since the default transaction isolation level cannot
be changed from READ COMMITTED.
Although explicit transactions are started and stopped with the BEGIN TRANSACTION, COMMIT, and ROLLBACK
commands, autocommit transactions do not require these statements.
Because each statement you execute against the database is contained
within its own autocommit transaction, these autocommit transactions
are affected by changing the transaction isolation level in the same
way that explicit transactions are.
As
the processes are blocked, and therefore cannot issue new commands to
the engine, checking for deadlocks is left to an outside process. The
process that checks for deadlocks runs only every 5 seconds. Because of
this your processes could be hung for several seconds before the
deadlock is identified and killed. In the event that a deadlock is
found, the interval that the deadlock detection process is run is
reduced, to as often as 100 milliseconds. Once no more deadlocks are
detected the interval is increased back up to 5 seconds.
When
SQL Server detects that a deadlock has occurred it must pick one of the
transactions to roll back. It does this by calculating the cost of
rolling back both transactions, and then rolling back the transaction
that costs the least to roll back. You can overwrite the logic by
setting the deadlock priority of the transaction with the SET DEADLOCK_PRIORITY
statement. This value can be set to any whole value from –10 to 10, LOW
(–5), MEDIUM (0), or HIGH (5). The transaction with the lower deadlock
priority will be killed no matter the rollback cost. The value of
MEDIUM (0) is the default deadlock priority.
